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Abstract 


This document captures the requirements for integrating IANA and RFC 
Editor state information into the Datatracker to provide the 
community with a unified tool to track the status of their document 
as it progresses from Internet-Draft (I-D) version -00 to RFC. 
Extending the Datatracker to hold document data from I-D version -00 
to RFC allows for increased automation between the Datatracker, IANA, 
and RFC Editor, thus reducing manual labor, processing errors, and 
potential delay. Therefore, this document also describes the 
requirements to make such automation possible. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6359. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


1. Introduction 


The IETF Datatracker is a web-based system for managing information 
about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison 
statements, and several other important aspects of the document 
process [IDTRACKER]. In this document, the term "IETF Datatracker" 
is used as a generic name for the existing tool used to track state 
changes as Internet-Drafts are processed. The word "IETF" in the 
name "IETF Datatracker" is not meant to limit use of the tool to the 
IETF document stream; this document expands use of the tool to the 
other streams described in [RFC4844]. 


The Datatracker is used to report on the status of I-Ds that have 
been submitted to the IESG for evaluation and publication. The 
Datatracker will be extended, according to the requirements defined 
in [RFC6174] and [RFC6322], to include tracking information about a 
document during its progression from version -00 to it being 
requested for IESG evaluation. However, the Datatracker, ICANN 
(performing the IANA function), and RFC Editor operate on separate 
systems with varying degrees of visibility into the processing that 
takes place once the stream managers have approved a document for 
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Bee 


2. 


publication as an RFC. This document defines the requirements for 
extending the Datatracker to include increased IANA and RFC Editor 
state information, so that the Datatracker covers the lifetime of an 
I-D from version -00 to RFC publication. 


Additionally, this document lists the processes between the IANA, RFC 
Editor, and Secretariat (via the Datatracker) that should be 
automated for accuracy and timely processing. While this document 
includes some details of the IANA, RFC Editor, and Secretariat 
process, this document does not define any of the processes. The 
processes are continually reviewed for process optimization and need 
to remain flexible to adapt to new changes in policy and environment. 
Processes are defined and set by each of the entities respectively. 


The IANA and RFC Editor are functions independent of the IETF. When 
an Internet-Draft enters the IANA queue, IANA retains ownership of 
its own data, state names, and tracking systems. Similarly, when an 
Internet-Draft enters the RFC Editor’s queue, the RFC Editor retains 
ownership of its own data, state names, and tracking systems. This 
document discusses how the data from the IANA and RFC Editor queues 
can be better reflected in the Datatracker to help inform the IETF 
community what the state of a document is throughout its lifetime. 


Prior to when an Internet-Draft is approved for publication as an 
RFC, the Datatracker is the definitive source for tracking IANA 
status information, and the IANA data is editable (by IANA and the 
Secretariat) in the Datatracker. After an Internet-Draft is approved 
for publication as an RFC, the IANA tracking system becomes the 
definitive source for tracking IANA status information, and the data 
can no longer be edited in the Datatracker. At that point, the data 
in the Datatracker is only a reflection of the data in the IANA 
tracking system. If there is a discrepancy between the two after 
this point, the data in the IANA tracking system is assumed to be 
correct. 


The RFC Editor’s tracking system is always the definitive source for 
tracking the RFC Editor status of a document. RFC Editor data is not 
editable via the Datatracker. The information in the Datatracker is 
always a reflection of the information in the RFC Editor’s tracking 
system. 


Integration of Data between the IANA and Datatracker 
1. IANA Information to Be Added to the Datatracker 
Currently, IANA reviews and touches IETF stream documents at 4 


different stages in the process from I-D to RFC: IETF Last Call, IESG 
Review, Document Approval (for publication), and RFC Publication. 
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Most of these state changes and issues are not captured in the 
Datatracker. For the IRTF (Internet Research Task Force) and 
Independent streams, the IANA review process begins when IESG Review 
is requested. For the IAB (Internet Architecture Board) stream, 
review would begin upon request for publication as an RFC. 


This section specifies the requirements for including additional IANA 
information in the Datatracker. 


- IETF Last Call Comments 


Currently, IANA reviews I-Ds that have been sent to IETF Last 
Call, inputs comments in their data system, and then emails their 
comments to authors, WG chairs, and then to the IESG. These 
comments are also manually entered into the Datatracker for the 
public record. However, it is difficult to determine whether the 
IANA issues have been resolved. To help facilitate tracking of 
IANA issues, a display is needed to show 5 new IANA substates, in 
a similar fashion to how RFC Editor State is currently shown in 
the Datatracker (see the example, later in this section, of how 
IANA state information could appear in the Datatracker for 
draft-—example-00). 


1) IANA Review Needed 


This substate will allow the community, Secretariat, and IANA 
to easily track which documents have or have not been reviewed 
by IANA. If this substate is NOT set to "IANA Not OK", "IANA 


OK -- Actions Needed", or "IANA OK -- No Actions Needed", the 
substate should be set to "IANA Review Needed" by default (this 
is the first substate for tracking IANA data). For documents 
that originate from a non-IETF stream, the default will be 
used. 

2) IANA OK -- Actions Needed 


This substate covers documents that require IANA actions, and 
the IANA Considerations section indicates the details of the 
actions correctly. 

3) IANA OK -- No Actions Needed 


This substate covers documents that require no IANA actions, 
and the IANA Considerations section indicates this correctly. 
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Note: The substate will be set to "IANA OK -- Action Needed" or 
"IANA OK -- No Actions Needed" (from "IANA Not OK") once any 
outstanding issues have been resolved. The comments section will 
be used to provide details in the History log about whether there 
are no IANA actions, the text is OK, or the issues have been 
resolved. 


4) IANA Not OK 


If IANA has issues with the text of the IANA Considerations 
section of a document, the substate should be set to "IANA Not 
OK", and the comment field should be populated with a 
description of the issues and questions. In addition to any 
questions IANA may have, IANA will also include in the comments 
field whether expert review is required, if the document is 
dependent on another document (e.g., document B registers 
values in a registry created by document A, which hasn’t been 
published yet), and if there is a registry expert appointment 
required. 


5) Version Changed -- Review Needed 


This substate will allow the community, Secretariat, and IANA 
to easily track which documents have been reviewed and 
subsequently when a version of an Internet-Draft in Last Call 
has changed, therefore requiring a second review of the 
document by IANA to ensure that either the IANA considerations 
have not changed, or any changes made to the document affecting 
IANA actions are clear. This substate applies to I-Ds that are 
in any substate except "IANA Review Needed" and "Version 
Changed -- Review Needed". 


When new versions are available, the Datatracker will 
automatically set the IANA substate to "Version Changed -- 
Review Needed". 


Information providing the status of the IANA review (one of the 5 
substates listed above) should be included as part of the evaluation 
message (sent to the IESG) so that IANA can determine if, and what, 
further action is required. 


All comments will be recorded in the History log. However, to reduce 
redundancy and manual effort, the Datatracker should provide the 
ability to receive state information and related comments from the 
IANA tracking system. There should be a notification that comments 
have been entered in the IANA-maintained system, and entry of those 
comments into the Datatracker and distribution of those comments to 
the authors should be automated. 
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- IESG Evaluation 


As not all documents receive an IETF Last Call, this state is 
sometimes the first time that IANA reviews a document. For a 
document that wasn’t IETF Last Called, IANA reviews the document, 
enters comments in their own tracking system, distributes email to 
authors and other interested parties (e.g., WG chairs, ISE 
(Independent Submissions Editor)), and then enters those same 
comments into the Datatracker, where they are recorded in the 
History log. In cases where a document was IETF Last Called, IANA 
checks for and reviews version changes and re-reviews documents to 
ensure that any identified IANA issues have been resolved. 


Comments will continue to be recorded in the History log. 
However, to reduce redundancy and manual effort, the Datatracker 
should provide the ability for IANA to enter substate information 
and related comments into the IANA tracking system, and 
distribution of those comments to the authors and entry into the 
Datatracker should be automated. 


Ideally, the authors will have responded to and resolved any IANA 
issues prior to the document being slated for an IESG telechat. 
However, if any document continues to have an "IANA Not OK", 
"Version Changed -- Review Needed", or "IANA Review Needed" 
substate and is slated for the IESG telechat, it should be called 
out in the Agenda Package. For example, it could appear as 
follows: 


o draft-example-00 
Title of Internet-Draft 
Note: John Doe (jdoe@example.com) is the document shepherd. 
Token: Jane Doe 
IANA: IANA Not OK 


This will ensure that IANA and the Area Directors (ADs) are aware 
that there are still IANA issues to be addressed prior to 
publication, or that initial or follow-up IANA review is required 
and not yet completed (in cases where the substate is listed as 
"IANA Review Needed" or "Version Changed -- Review Needed"). 
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Document Approved for Publication 


Once a document has been approved for publication, the document 
enters the IANA queue and is tracked using IANA-defined states. 
This state information is not currently available via the 
Datatracker. In order for the community to view the IANA 
processing states without being redirected to the IANA queue, the 
Datatracker should be extended to include IANA state information 
as defined by IANA. For example, IANA state information could 
appear in the metadata portion of the document as follows: 


Document type: Active Internet-Draft (FOO WG document) 
Last updated: 2010-09-20 

State: RFC Ed Queue 

RFC Editor State: EDIT IANA 

IANA State: In Progress 

Intended status: Proposed Standard 


IANA state-change information will link to the IANA queue, and 
will be captured as a line item in the History log. IANA will 
notify the Datatracker when changes are made in the IANA queue. 


Once the IANA actions have been completed, the Datatracker History 
log will be updated to include the actions completed by IANA 
(i.e., the author-approved actions). This information will 
include the same information that is sent to the RFC Editor upon 
completion of IANA actions. 


The IANA State field may be any of the states defined by IANA. 

The list of IANA state names in use at the time this document was 
published is provided in Appendix A; however, IANA states are 
defined by IANA and are subject to change. If there are any 
discrepancies between the state names listed in this document and 
those listed on the IANA queue page 
(http://www.iana.org/about/performance/ietf-draft-status/), the 
IANA queue is definitive. States may be added or removed by IANA; 
TANA will work with the IETF Administrative Oversight Committee 
(IAOC) to update the Datatracker as necessary. 


RFC Publication 


References to the I-D are updated to refer to the RFC once it is 
published, and minor updates may be made to match the published 
RFC. This data will be tracked in the Datatracker to show when 
the references in the IANA registries were updated to include the 
newly assigned RFC number. 
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2.2. Future IANA Information to Be Available via the Datatracker 


The document "Definition of IETF Working Group Document States" 
[RFC6174] includes the following: 


4.3.1. Awaiting Expert Review/Resolution of Issues Raised 


This tag means that someone (e.g., an author or editor of the 
WG draft, or a WG Chair) has initiated an expert review of the 
document and the review has not yet been completed and/or the 
resolution of issues raised by the review has not yet been 
completed. Examples of expert reviews include cross-area 
reviews, MIB Doctor reviews, security expert reviews, and IANA 
reviews. 


WG drafts tagged with this annotation should retain the tag 
until the review is complete and possibly until any issues 
raised in the review are addressed. 


IANA is in the process of documenting how an expert review is 
conducted during the lifetime of an Internet-Draft. Once the process 
has been defined, the Datatracker should be updated to indicate if a 
document requires "Expert Review" [RFC5226] (either for the entire 
document or a portion thereof); if the expert reviewer has issues 
with what they are being requested to review; and, if applicable, 
whether the expert reviewer has approved or rejected the requested 


registration(s). There may be a need to complete expert reviews 
again before publication of a document if there have been changes to 
the text relevant to the review by the expert. In cases where a new 


registry is being created in the document, an indicator of whether an 
expert needs to be appointed by the IESG would also be useful. 


2.3. Permissions to Change IANA State Information 
IANA state changes should be automated, but IANA should have the 
ability to log in to the Datatracker to manually update the system as 
well. 


The IETF Secretariat should also have the ability to change the IANA 
state if necessary. 


It is expected that this feature would only be used to correct 
issues; it is not intended to be part of regular operations. 
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3. Integration of Data between the RFC Editor and Datatracker 


For quite some time, the RFC Editor was seen as a black box, where 
documents were submitted for publication, went through some process, 
and came out as RFCs. Over time, the community asked for a more 
transparent process; thus, state information was made available on 
the RFC Editor website. Currently, some of that state information is 
available from the Datatracker. However, for additional transparency 
about the RFC Editor process, the Datatracker should be extended to 
hold supplementary RFC Editor state and process (e.g., MISSREF) 
information. This section defines the requirements for RFC Editor 
state information to be added to the Datatracker to provide more 
transparency and allow for a unified end-to-end tracking system. 


3.1. RFC Editor Information to Be Added to the Datatracker 


Once a document has been approved for publication, the document 
enters the RFC Editor queue and is tracked using RFC-Editor-defined 
states. Some RFC Editor state information is currently available via 
the Datatracker, but the information is not stored in the History 
log. RFC-Editor-defined state information will continue to be shown 
as is done currently. In addition, a line item will be entered into 
the History log each time a document changes state. The RFC Editor 
shall continue to provide a queue file to allow data extraction; in 
addition, there will be a machine-readable notification to the 
Datatracker when state changes are made. 


RFC Editor state information should continue to appear in the 
metadata portion of the document available using the Datatracker. 
For example, an entry might appear as follows (including the IANA 
State information): 


Document type: Active Internet-Draft (TLS WG document) 
Last updated: 2010-09-20 

State: RFC Ed Queue 

RFC Editor State: EDIT IANA 

IANA State: In Progress 

Intended status: Proposed Standard 


The RFC Editor State field may be any of the states defined by the 
RFC Editor. The list of RFC Editor state names in use at the time 
this document was published is provided in Appendix B, but RFC Editor 
states are defined by the RFC Editor and are subject to change. If 
there are any discrepancies between the state names listed in this 
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document and those listed on the RFC Editor queue page 
(http://www.rfc-editor.org/queue2.html), the RFC Editor queue is 
definitive. States may be added or removed by the RFC Editor; the 
RFC Editor will work with the IAOC to update the Datatracker as 
necessary. 


Although RFC Editor state information is already available in the 
Datatracker, the Datatracker should be updated to include some 
additional data that may help individuals understand the status of 
their document. In particular, the Datatracker should be updated to 
include the following data: 


1) links to AUTH48 pages 


AUTH48 pages provide information about which authors have approved 
the document for publication, whether AD approval is required, and 
sometimes a summary of issues that need to be resolved before the 
document can move forward. 


2) links to the cluster pages 


Clusters are defined as documents with normative reference 
dependencies, and documents that have been requested for 
simultaneous publication. (For more information, see 
http://www.rfc-editor.org/cluster_def.html.) The cluster pages 
provide a view of the entire set of state information for 
clustered documents. 


Note: The RFC Editor has been working with the cluster data to 
provide the community with accurate state information at the 
appropriate level of detail. The RFC Editor database may require 
significant updates before this data can be integrated with the 
Datatracker. 


3) RFC metadata upon publication 


The RFC Editor will notify the Datatracker when a new RFC has been 
published, and the Datatracker should have the ability to 
automatically update the relevant fields with data related to the 
published RFC. In particular, the RFC number will be recorded in 
the Datatracker. However, note that all fields are subject to 
change during editing and should be updated; for example, the 
document title and the list of authors are sometimes changed, and 
character counts and page counts are always changed. 
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4) notation when documents are withdrawn from the RFC Editor queue 


If a document is to be removed from the RFC Editor / IANA queues, 
the responsible party (e.g., AD or Secretariat) should change the 
state of the document in the Datatracker to something other than 
"RFC Ed Queue". The Datatracker should provide a text box to 
allow the responsible party to record details about the state 
change. The state change and the related details will be recorded 
in the History log. The state change in the Datatracker will 
trigger an email message to the RFC Editor and IANA as 
notification that the state of the document has been set to the 
newly assigned state, with the details provided in the text box. 
The RFC Editor and IANA will update their queues accordingly, and 
the document will disappear from their respective queues. 


4. Other Updates to the Datatracker 
While the primary goal of this document is to update the Datatracker 
to display the IANA and RFC Editor process state information, the 
Datatracker could hold additional data for use by IANA and the RFC 
Editor that would allow for increased automation, thus reducing the 
potential for delays and processing errors. This section defines 
requirements for updates to the Datatracker to eliminate some of the 
administrative tasks currently performed by staff. 

4.1. Datatracker to IANA 


When a document is approved for publication, data will be provided in 
a machine-readable format and will include (in addition to the usual 
Document/Protocol Action emails) the data requested by the RFC Editor 
in Section 4.2. 
4.2. Datatracker to RFC Editor 

When a document is approved for publication, data will be provided in 
a machine-readable format and will include the following (in addition 
to the usual Document/Protocol Action emails): 

- I-D String 

- Document Title 

- Author List 


- Author Email Addresses 


- Author Organizations (if available) 
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- Expedited Goal Date (if applicable) 


Note: This field needs to be editable for post-approval 
changes. 


- Publication Status (as defined in [RFC2026]) 
- Consensus (yes/no) 


- Source (Working Group or Research Group name, Individual, 
or alternate-stream name) 


Note: The RFC Editor database may require updates before 
Research Group data can be received from the Datatracker. 


- IESG Contact 
- Document Shepherd <email> 


Note: This is the individual currently listed in the 
"Personnel" section of a Document/Protocol Action. 


- IANA Actions Required 


Most of these items are already stored in the Datatracker. However, 
the following fields need to be added: 


- Expedited Goal Date 
- Consensus (yes/no) 


- Document Shepherd <email> 


TANA Actions Required 


"Consensus" is as used in [RFC5741]; it determines the appropriate 
Status of This Memo text to be applied to IETF and IRTF documents. 
The Consensus field should be set by the responsible individuals, and 
it should be listed in the Agenda Package provided before an IESG 
telechat so that the Area Directors can quickly review the status of 
the documents under review and correct the field if Consensus was not 
received. 


Additionally, the Agenda Package provided before an IESG telechat 
should show the expiration date of the IETF Last Call. This will be 
helpful for the ADs and the Secretariat to track the IETF Last Call 
timeline. 
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When a document has been added to the RFC Editor queue (i.e., shows 
an RFC Editor state in the Datatracker), an automated note should be 
sent to the Secretariat as acknowledgment that the announcement has 
been received. 


4.2.1. Notifications 


The Datatracker should notify the RFC Editor and the Sponsoring AD 
when a version of an I-D has been made available after the document 
has been approved for publication. 


Additionally, the Datatracker should notify the RFC Editor and IANA 
when the state of an I-D has been moved to something other than "RFC 
Ed Queue" or "RFC Published" -- that is, when it should be removed 
from the RFC Editor and IANA processing queues. See item 4) in 
Section 3.1 for more details. 


4.2.2. Datatracker Extensions for Alternate Streams 


Once the Datatracker has been updated for the alternate streams 
[RFC6322], the Datatracker should be updated so that the following 
are automated: 


- The Datatracker should not expire any I-Ds that are under review 
for publication. 


- The Datatracker should automatically notify the approving body 
when an I-D that is under review has been updated (i.e., a new 
version has been made available). 


- The Datatracker should be updated so that the Agenda package lists 
I-Ds according to the stream that requested publication. This 
should help provide additional clarity during IESG Reviews, as 
there will be a clear indication of from which stream a document 
originates. 


4.2.2.1. Publication Requests 


RFC 6322 [RFC6322] lists the requirements for extending the 
Datatracker to account for alternate-stream states and annotations. 
In particular, the document introduces the "Sent to the RFC Editor" 
state, which means the document is complete and has been sent to the 
RFC Editor for publication. 


The Datatracker will provide a means for the alternate streams to 
generate a uniform publication request. Using the Datatracker, the 
stream managers should be able to generate a publication request that 
contains the relevant information for any approved I-D. 
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Additionally, the Datatracker will provide the data (the same data 
provided for any IETF publication request -- see Section 4.2) ina 
machine-readable format. This data will be available to the IANA and 
RFC Editor, so that data entry into the IANA and RFC Editor systems 
can be automated. 


This update will allow the IANA and RFC Editor to handle documents in 
a similar manner, regardless of the document’s stream. 


4.3. Reporting Requirements 


The Datatracker should have a "Show Discrepancies" feature. It 
should show all records in the Datatracker that fit certain criteria 
(that seem to be a discrepancy). In addition to showing data on 
screen, it should send an email to defined interested parties at 
regular intervals (e.g., weekly). This feature will only be 
available to a subset of individuals (namely, IANA, RFC Editor, and 
the Secretariat), to ensure that their queues are in sync. This will 
be especially helpful as the Datatracker is extended (now and in the 
future), to ensure that all parties are receiving the correct 
messages/data. 


An initial set of discrepancies should be defined, and additional 
discrepancies could be defined over time. For example, the initial 
set of discrepancies could include the following: 


- Show drafts that have passed through the state "Approved 
Announcement sent" but do not have an RFC Editor state. 


- Show drafts that have IANA state "In Progress", but RFC Editor 
State is not equal to "IANA" or does not contain "*A" (see 
Appendix B). 


- Show drafts that have IANA state "Waiting on RFC Editor" or 
"RFC-Ed-Ack", but RFC Editor State is "IANA" or contains "*A" 
(see Appendix B). 

- Show drafts that have a state of something other than "RFC Ed 
Queue" or "RFC Published" that are listed in the RFC Editor or 
IANA queues. 


5. Security Considerations 


This document does not propose any new Internet mechanisms, and has 
no security implications for the Internet. 
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Appendix A. Current IANA States and Definitions 
The currently defined IANA states are listed below. 


* No value (blank) - A new document has been received by IANA, but 
no actions have been taken 


* In Progress - IANA is currently processing the actions for this 
document 
* Waiting on Authors - IANA is waiting on the document’s authors 


to respond 


* Waiting on ADs - IANA is waiting on the IETF Area Directors to 
respond 


* Waiting on WGC - IANA is waiting on the IETF Working Group 
Chairs to respond 


* Waiting on RFC Editor - IANA has notified the RFC Editor that 
the actions have been completed 


* RFC-Ed-Ack - Request completed. The RFC Editor has acknowledged 
receipt of IANA’s message that the actions have been completed 


* On Hold - IANA has suspended work on the document 


* No IC - Request completed. There were no IANA actions for this 
document 


IANA states are defined by IANA and are subject to change. If there 
are any discrepancies between the state names listed in this document 
and those listed on the IANA queue page 
(http://www.iana.org/about/performance/ietf-draft-status/), the IANA 
queue is definitive. 
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Appendix B. Current RFC Editor States and Definitions 
The currently defined RFC Editor Queue states are listed below. 
* AUTH = Awaiting Author Action 


* AUTH48 = Awaiting final author approval 


* EDIT Approved by the stream manager (e.g., IESG, IAB, IRSG, 
ISE), awaiting processing and publishing 


* IANA = RFC-Editor/IANA Registration Coordination 


* IESG 


Holding for IESG Action 
* ISR = Independent Submission Review by the ISE 


* ISR-AUTH = Independent Submission awaiting author update, or in 
discussion between author and ISE 


* REF = Holding for normative reference (followed by I-D string of 
referenced document) 


* RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 


* TO = Time-out period during which the IESG reviews document for 
conflict/concurrence with other IETF working group work 
(followed by date) 


* MISSREF = Awaiting missing normative reference 


RFC Editor states are defined by the RFC Editor and are subject to 
change. If there are any discrepancies between the state names 
listed in this document and those listed on the RFC Editor queue page 
(http://www.rfc-editor.org/queue2.html), the RFC Editor queue is 
definitive. 


Currently, there are also a couple of state annotations used in RFC 
Editor state-change emails. These do not alter the Datatracker in 
any way, but are listed here for completeness: 


*A 
*R 


indicates that IANA actions are required 
indicates potential REFerence holds 
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